Public service announcement - Possible server breach and outages In the past 7 days, our services (authentication, multiplayer matching, mod portal, etc.) experienced multiple outages. One of them was caused by one of our service providers and resulted in a roughly 6 hour long outage on Tuesday evening. This was a widespread outage all over the internet caused by problems with Amazon's AWS S3 and also affected other services, for example Instagram, Imgur or Trello. The other 2 outages were the result of a possible security breach of one of our servers, acting as the master content server at the time. On Friday, just before midnight UTC, we were informed by Linode (our server provider), that a brute force SSH attack was originating from that server, targeting a specific IP in the OVH network. As a precaution, the server was cut from all network traffic, which caused a short outage. We haven't managed to determine, whether that attack was caused by a bug in some software or a runaway process, or if it was caused by someone who managed to gain access to the server. We can't say if it's possible to spoof the IP address of an attack of this kind and make it look like the attack is coming from someone else. As a security measure, we have destroyed and redeployed all 3 content servers we currently operate, improved our firewall and automatic banning rules and invalidated passwords and SSH keys. All the releases that are available for download were checked and none of them were modified. We apologise for any inconvenience we might've caused by these outages. Additional map info The Trello card to improve our map has been sitting in our queue for a very long time, and since I wanted to program some low hanging fruit for 0.15, I decided to pick this. Let me present how far I got. Now when I open the map view, it shows the map view settings mini-panel on the side (icons are temporary), which can be used to toggle different kind of additional info on the map. The logistics area visualisation It wasn't really possible to see the roboport coverage in the scale of the whole factory and I missed that a lot, so it was the first thing to be done. Now I can clearly see why did I get alerts of missing construction robots in the left part of the map. It can be also used to find all these small gaps in the coverage or off-by-one alignment issues. I'm also considering to show the roboport connections in this view, or as additional option. The electric network visualisation This one might be especially useful when you want to find out the reason of electricity breach. As with the previous one, it gives even more incentive to build electric network in OCD friendly way, as all the circumstantial electric pole placements are more than visible in this view. The pollution The pollution works the same as before, but it can be turned on and off the same way as other things. This means you'll no longer have to toggle the detailed info to see your base clearly through the pollution. Map interaction This was the most obvious step of all. You can open locomotives and train stations from any distance, you can access them from the train manager, but you couldn't open them by clicking in the map. It is possible now. Custom tags As the map shows train station names, people were actually using stations to put markers on the map. But as its kind of a hack, and it clutters the train destination selection dialog it needs a proper solution. This is why we have the custom tags now. It can be either text only, icon or both. As you can see it can be used to mark different parts of the factory, it can be used in multiplayer to coordinate different kind of tasks and I don't doubt that people will use it to draw penises or other 'creative art' on the map as well. Resource patch inspection Searching for the best patch around was quite tedious, as you had to walk to the locations and guess how much ore it contains by hovering over several ore patches. It is not needed anymore, as a player can just hover over the patch on the map to see how much it contains. As the area was discovered by radar, or by the player manually, there is no harm in providing this information. It also helps colorblind people as they couldn't distinguish the ore types by color so well. Other improvements There are other things we are considering. Just to be sure, this doesn't mean a promise or a plan, just an idea, that might or might be not implemented: Extend the custom tags, so they can refer to rectangular area. Interactive (clickable) electric and logistics networks that open the window with detailed info. Integrate the interaction into the train stop selection when adding new items to the train schedule Integrate the interaction into the train to allow semi-automatic one-time train order that wouldn't be limited to train stations. Be able to zoom from the map view directly to the world. Things not covered by radars would just be covered by some kind of blackness. Better map colors, more different colors for entities, so you would see whether it is an assembling machine, electric pole or turret. Option of Higher resolution of map. If we have 4 pixels per tile in the map it could be nicer and also provide more information when zoomed in Smarter map info. Especially in the high resolution option, the belts could theoretically remember the resource they are used for (if it is one purpose belt), and draw line of the color on them. Assembling machines could have a pixel(s) inside the square that would depend on the recipe. Etc. I would actually like to know what other things you might want, or what things from this list you find the most needed. As always, we can’t wait to read your reactions and feedback on our forums.
While all us minions and assembling humans are furiously working on 0.15, today I would like to present to you what I have been working on lately - new graphics for resources, of course including high res and the new uranium ore. In the second part of the article I will get to an old/new topic about concrete.
Hello, the office has had a very lively atmosphere this week. With some very productive team discussions taking place, we reach another Friday with an optimistic outlook of the weeks to come.
0.15 status Work has been going swiftly on 0.15, but there are still many major topics we have left to close. We mentioned previously that our estimate for release would be near the end of February, and while this has been our internal goal, we won't quite be able to make it. One of the main reasons for this delay is us underestimating how long it would take to stabilize 0.14 and the new multiplayer code. We thought that because it was a relatively small 'major' release, that it would not take much time to make it stable. However the great community members playing the experimental version kept finding bugs for us to fix, and even now there are still several 0.14 bugs being identified and fixed in 0.15. The extending bug fixing of 0.14 was no doubt necessary, but it has led us to be somewhat behind schedule on several features of 0.15. Our current optimistic estimate is that we will be able to release an experimental version of 0.15 at the end of March, and we will keep you all up to date on its progress.
Hi everyone. About half a year ago whenever I was sitting deeply in Factorio and when I needed to spend time in my phone, I was reading FFF or Factorio forum. Later when I decided to move - I suddenly realized that Wube is the most logical target to apply my crazy mind. All thanks to those FFF and you guys. Now I am writing another FFF myself which, looking back at those times, gives me ripping apart feelings (which I believe is a good thing :)).
The programmable speaker There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life. So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things: Show configurable GUI alerts and play audio alerts based on circuit conditions. Play audio samples as controlled by the circuit network in a way that simple songs can be created. The entity graphics are placeholder programmer graphics. Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals. And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network. Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated. Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low". I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit. There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF. The map download struggle (Technical) For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in "Pending" or "Duplicates" or "1/0 Magic", but after a few months some other person would report it again. I seem to have a habit of obsessing over these rare "unfixable" bugs (audio mixer crashing, vsync performance issues, non-pixel-perfect sprite drawing), so I started looking into this map downloader issue. First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio. But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic. The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :) This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen. Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue. In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections. As usual, let us know what you think at the forums.
Hello, a wave of illness has afflicted the team these last few weeks, but things are starting to pick up again. With the collective health of the office back to normal, progress is advancing well on the features for 0.15.
Alpha blending and pre-multiplied alpha From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha. When the GPU is figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'): You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque. In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation: Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha. Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending: This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering. For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke. Textures with pre-multiplied alpha also produce better results in texture filtering , which is probably the main reason why they are so widely used in the videogame industry.
Hello, It has been very quiet in the office this week, the calm twilight between Christmas and the New year.
